home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Just Call Me Internet
/
Just Call Me Internet.iso
/
archives
/
com
/
uucp
/
upl_0495.lzh
/
EXTRA
/
HSMODA04.LZH
/
MFP_X.TXT
< prev
next >
Wrap
Text File
|
1994-05-07
|
22KB
|
535 lines
MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
***********************************************
(Note for the English reading people: The English version is appended on
the German, look for it!)
Dies sind Treiber fr die mit MFPs (z.B. Schaltkreis MC68901 von
Motorola) ausgestatteten seriellen Schnittstellen der Ataris. Sie
funktionieren zusammen mit DRVIN.PRG oder einem gleichwertigen Ersatz.
Einfhrende Bemerkungen finden sich in 1_README.TXT.
Allgemeines
-----------
Momentan besitzen alle MFP*.PRG die gleichen Einstellmglichkeiten durch
SETTER.
Der serielle Teil des MFP, die USART, ist nicht ganz so leistungsfhig wie
beim SCC. Dadurch sind die MFP-Schnittstellen gegen Zeitknappheit der CPU
allergischer als die SCCs und reagieren leichter mit Zeichenverlusten.
MFP.PRG
-------
MFP.PRG ist fr den sogenannten ST-MFP gedacht, der ab Adresse $FFFFFA01
liegt und in ST, STE, MegaST, MegaSTE, TT, Stacy und STBook vorhanden ist.
Im Falcon ist dieser MFP ebenfalls vorhanden, der USART-Teil aber anders
(=nicht) benutzt, so da MFP.PRG NICHT fr den Falcon ist. Dieser Treiber
trgt sich als BIOS-Gert 6 und mit dem Namen "MODEM1" ein.
MFP_TT.PRG
----------
MFP_TT.PRG untersttzt den sogenannten TT-MFP ab Adresse $FFFFFA81, der
bisher nur im TT vorkommt. Der Treiber trgt sich als BIOS-Gert 8 und mit
dem Namen "SERIAL1" ein.
MFP_FALC.PRG
------------
MFP_FALC.PRG ist fr die bastelfreudigen Falcon-Besitzer gedacht, die die
von Atari nicht herausgefhrte serielle Schnittstelle des MFP
herausgefhrt haben. Der Treiber trgt sich als BIOS-Gert 6 und mit dem
Namen "MODEM1" ein.
Hier noch eine Mail, die ich aus der Mausgruppe Atari.Hard gefischt habe,
bezglich Herausfhrung der MFP-Schnittstelle des Falcon:
-------------------Mailanfang-------------------------
Gruppe: Atari.Hard
#A5003@WI2 (So 26.09.1993, 08:18) MFP-Serielle im Falcon
Von: Martin Liebeck @ WI2
Wg.: MFP-Serielle im Falcon
Von : Martin Liebeck @ WI2 (Sa, 25.09.93 09:55)
Ein Tip fr Alle, die gerne eine zweite Serielle an ihrem Falcon htten:
die MFP-Serielle wird unter Port Nr. 6 vom TOS (4.01) untersttzt und kann als
Dreidrahtschnittstelle verwendet werden. Atari hat hier wohl lediglich die
Buchse und die Treiber gespart...
RXD liegt an Pin 10 des MFP und ist nach Masse gelegt. In meinem Layout wird
hierzu eine ca. 3mm lange Leiterbahn auf der Platinenoberseite von Pin 10 zu
einer Durchkontaktierung nach Masse verwendet. Diese muá vorsichtig (nicht zu
tief, Multilayer!) unterbrochen werden. TXD bekommt man an Pin 9 des MFP.
Ich habe noch mit einer 1488/1489 Kombination auf RS232-Pegel gewandelt und die
Pins 1 und 3 von Midi-in als Verbindung zur Auáenwelt verwendet.
Garantie, insbesondere fr ruinierte Boards, bernehme ich natrlich keine. Ich
weiá auch nicht, wie hhere TOS-Versionen als 4.01 mit dem MFP verfahren. Am
Besten erst mal an Pin 9 messen, ob ein Signal kommt. Viel Spaá beim lten, es
lohnt sich.
Gruá Martin.
---------------Mailende-----------------
MFP_BAST.PRG
------------
MFP_BAST.PRG ist fr die Bastler gedacht, die sich einen TT-kompatiblen
zweiten MFP in einen nicht-TT eingebaut haben. Dieser Treiber liegt
momentan nicht bei. Wer ihn braucht, mge sich bitte melden. Der Treiber
wird sich mit dem Namen "SERIAL1" auf das erste freie BIOS-Gert
installieren.
Im Folgenden geht es hauptschlich um MFP.PRG:
Dies ist ein Software-Beschleuniger und Patch fr die serielle
Schnittstelle Modem1 der Atari-Computer. Es beseitigt nicht nur den auch
im TOS2.06/3.06 noch vorhandenen RTS/CTS-Handshakefehler, sondern erhht
durch seine optimierten Routinen die mgliche bertragungsrate wesentlich.
Sptestens wenn Fragen auftreten sollte man diesen Text komplett lesen und
erst danach seiner Umwelt oder mir die verbliebenen Fragen stellen. Bei
Updates und Zeitmangel zuerst einen Blick nach ganz hinten, Abschnitt
"Versionen"!
Kompatibilitt zu HSMODEM1
--------------------------
Wird MFP.PRG als letzter oder als einziger Treiber gestartet, so sollten
alle Programme, die mit den HSMODEM1-Versionen funktioniert haben, auch
mit diesen Treibern laufen, wenigstens wie bisher auf MODEM1.
Einsatzmglichkeiten, Voraussetzungen, u.v.m.
---------------------------------------------
Mag!X
Versionen ab 2.00 dieses multitaskfhigen Betriebssystems (es ist im
Gegensatz zum aktuellen MultiTOS nicht nur ein Aufsatz und wesentlich
schneller) haben korrekte Routinen zur Schnittstellen-Bedienung. Die
entsprechenden GEMDOS-Funktionen fehlen in Mag!X 2.00 aber noch.
Interessant ist das Mag!X-Multitasking auf 8MHz-STs bei 38400Bd-Empfang:
(mit einem NVDI ab Version 2.50 vom 28.10.1993) Man kann im Vordergrund
mit der Maus wirtschaften und einen Text schreiben (getestet mit Everest),
whrend im Hintergrund GSZRZ 3.5 fehlerfrei empfngt. Mit Mag!X ab Version
2.00 sollte man die Interruptroutinenmodifikation im MFP.PRG abschalten,
da Mag!X bereits modifizierte Timerroutinen hat. Wenn MFP.PRG da noch
etwas einhngt, wird es ein bichen langsamer.
Diese Treiber sind ein Ersatz fr andere Patches (nicht nur fr Modem1),
wie z.B. RS232ENC oder TURBOCTS.
Die Schnittstelle Modem1 kann ohne Zusatzhardware maximal 19200Bd
erreichen. Daran ndert auch MFP.PRG nichts. Es ersetzt aber die langsamen
und zum Teil fehlerhaften Routinen des TOS durch schnelle und hoffentlich
fehlerfreie. Mit Zusatzhardware, wie (dem von mir entwickelten) RSVE,
RS-Speed (von Stephan Skrodzki) oder anderen knnen hhere Datenraten
realisiert werden. Z.B. erlaubt RSVE auch die Einstellung von 38400, 57600
und 115200Bd. MFP.PRG sorgt dann im Rahmen der Hardware-Mglichkeiten fr
einen wesentlich hheren Datendurchsatz (cps-Rate). Der komplette Bauplan
fr RSVE liegt als RSVE.LZH in Mailboxen, auf jeden Fall in der Maus
Berlin (@B). Die Fertigversion von RSVE gibt es direkt bei mir.
Wenn jemand meint, allein mit Software Modem1 mit mehr als 19200Bd
betreiben zu knnen: Das geht im Synchronbetrieb des MFP (Abschalten der
Taktteilung /16). Dabei ist eine fehlerfreie Funktion aber ausschlielich
beim Senden mglich, NICHT beim Empfang.
Ich arbeite mit einem 8MHz ST, ohne CPU-Beschleuniger. Ich halte wenig
davon, immer neue und schnellere Computer zu kaufen und diese durch lahme
Software bis zum Stillstand zu bremsen. Das TOS ist eine lahme Software,
kein Wunder, es ist inklusive der Interruptroutinen in C programmiert (es
sieht so aus). MultiTOS ist eine noch grere Systembremse. Mag!X ist
genau das Gegenteil.
Fehler anderer Programme
------------------------
Mit Rufus 1.11rel9 steht der Rechner nach dem Auflegen einiger Modems (RXD
und TXD leuchten beide, nichts geht mehr). Abhilfe: Rufus 1.20 oder neuer
benutzen.
Wie schnell geht es?
--------------------
Das Problem bei einer seriellen bertragung mit einer bestimmten
Geschwindigkeit (hier in Baud angegeben) ist nicht das Senden der Zeichen,
sondern deren Empfang. Der MFP puffert nur ein empfangenes Zeichen und
meldet es der CPU per Interrupt. Die CPU mu dieses Zeichen fr eine
fehlerfreie bertragung aus dem MFP abholen, bevor er das nchste Zeichen
komplett empfangen hat. Wenn ich sage, der Betrieb bei ... ist zuverlssig,
so bedeutet dies, da die CPU bei der maximal mglichen
Empfangs-Zeichendichte (keine Pause zwischen Stoppbit des vorigen und
Startbit des folgenden Zeichens) jedes Zeichen rechtzeitig abholt.
Ein 8MHz ST (RSVE eingebaut) kann mit TOS und HSMODEM1 eine fehlerfreie
Datenbertragung mit 38400Bd realisieren. Mit einem HSMODEM1 ab dem
21.05.1993 funktioniert auch der Empfang (Senden sowieso) mit 57600Bd auf
8MHz STs, wenn die Interruptroutinenmodifikation (FASTINT) eingeschaltet
ist.
Derzeit erreicht ein 8MHz ST mit GSZRZ Version 3.3 von Michael Ziegler bei
einer ZMODEM-bertragung und 38400Bd mehr als 3600cps, wenn NVDI
installiert und der Blitter ausgeschaltet ist. Ohne NVDI sind es etwa
300cps weniger, da GSZRZ lange an seiner Dialogbox zeichnen lt. Den
Blitter kann man in den meisten Fllen auch zugeschaltet lassen. Sollten
aber Empfangsfehler auftreten, dann den Blitter abschalten.
ZMODEM-bertragung ber die Filefunktionen bringt mit einem GSZRZ ab 3.5
mehr als 5400cps bei 57600Bd.
Die angegebenen Datenraten gelten fr direkte Rechnerkopplung. Fr langsame
Modems und schlechte Telefonleitungen sind die Treiber nicht verantwortlich!
Zyxels knnen bei 16800zyx/v42bis und ASCII-Texten 3800cps erreichen,
Zyxel+ bei 19200zyx noch mehr. Andere 14400/v42bis-Modems liegen bei etwa
3300cps.
Die von mir entwickelte Hardware ST_ESCC hat auch bei 115200Bd noch
keinerlei Probleme, selbst bei Tastaturtippen unter normalem TOS, da sie
ber einen 8 Byte groen Empfangs-FIFO verfgt. Sie beschleunigt aber
nicht MODEM1, sondern realisiert zwei zustzliche schnelle Serielle.
57600Bd auf 8MHz und 16MHz 68000er ber _MODEM1_
------------------------------------------------
57600Bd ist fr Modem1 auf (Mega)ST(E) die magische Grenze, die
auch nur mit leichten Modifikationen im TOS erreicht wird. 115200Bd werden
wohl auch in Zukunft nur im Polling und nicht im Interruptbetrieb mglich
sein.
Bei mir funktionieren 57600Bd auf einem 8MHz-ST mit TOS2.06. Ich bin mir
aber nicht sicher, ob es auch mit anderen (lteren) TOS-Versionen
funktioniert.
Da ich immer wieder gefragt werde, wie man 57600 fehlerfrei erreicht:
Blitter aus, keine DMA-Zugriffe whrend Dateibertragung (in den Filepuffer
des ZMODEMs mu bei Empfang das ganze File passen), keine Joysticks mit
Autofire oder DCF-Uhren am Joyport. Dann testweise alle residenten
Programme und ACCs entfernen und nur die wieder benutzen, die nicht stren.
Die Konfiguration
-----------------
Die Konfiguration erfolgt durch das SETTER.TTP. Zur Bedienung siehe
SETTER.TXT.
FASTINT:
MFP.PRG kann den Timerinterrupt des TOS modifizieren, um so 57600Bd mit
8MHz-68000 ber MODEM1 zu ermglichen. Sollte man auf TTs/Falcons und
unter Mag!X >=2.0 abschalten, ebenso bei Experimenten mit anderen
Betriebssystemen. Wenn man mehr als ein MFP*.PRG gleichzeitig nutzt,
sollte diese Option hchstens in einem davon eingeschaltet sein.
Funktionsweise (fr Interessenten):
Es hat sich gezeigt, da es ausreichend ist, wenn die Routine (GEMDOS-Uhr)
in NEXT_TIM (negative LineA-Variable) mit einem IPL < 6 aufgerufen wird,
um auf 68000/8MHz den 57600Bd-Empfang zu ermglichen. Also hnge ich ein
Programmstck ein, da den IPL auf 5 heruntersetzt. Diese Vorgehensweise
ist nicht vllig unkritisch, bringt aber nur Probleme, wenn andere
Programme ebenfalls derartige Fummeleinen anstellen.
RSVE:
(Nur fr Nutzer der RSVE-Hardware interessant. Andernfalls mit Nein
antworten.) MFP.PRG kann den Cookie RSVE anlegen und macht damit das
RSVE_SET.PRG berflssig. Die Funktion von HISP wird automatisch mit
ausgelst.
HISP:
Dieser Konfigurationspunkt teilt die bei RSVE (und RS_Speed) mglichen
hohen Baudraten den Fcntl-TIOC?BAUD-Funktionen mit (anstelle der
150/134/110).
REPL:
MFP.PRG kann Baudraten umlegen. Dies ist nur zusammen mit RSVE oder
RS-Speed ntzlich, falls Programme weder RSVE/RS_Speed kennen noch
110/134/150Bd einstellen knnen. So kann man die Einschaltung von 38400Bd,
die bei ahnungslosen Programmen normalerweise durch Einstellen von 110Bd
erfolgt, auf das Einstellen von 19200Bd legen. Man gibt (wie es SETTER
beschreibt) zuerst die zu ersetzende alte Baudrate und dann (auf den
nchsten Platz) die dort hinzulegende hohe Rate an, und zwar ganz exakt.
Der erste als "ungltig" gekennzeichnete Platz beendet die Suche nach
Umbelegungen. Will man nichts umlegen, gibt man berall "u" an. Die
Baudraten 115200/57600/38400 liegen mit der Hardware RSVE ohnehin auf
150/134/110, sie dorthin umzulegen ist sinnlos. Die Umlegungen sind fr
Programme unsichtbar und erscheinen nicht in den Fcntl TIOC?BAUD.
DTR: (nur bei MFP.PRG)
Das DTR(Data Terminal Ready)-Signal wird beim Start dieses Treibers
einmalig auf den hier angegebenen Wert gesetzt. Eine Aktivierung mit "Ja"
entspricht der Arbeitsweise des TOS, eine Deaktivierung mit "Nein"
verhindert das "ungefragte" Abheben eines entsprechend konfigurierten
Modems.
RBL:
Wenn man hiermit nichts anzufangen wei, einfach 256 einstellen. Hier wird
die Empfangspufferlnge in Byte eingestellt. Sie darf maximal 65534 und
minimal 16 betragen. Werte auerhalb dieses Bereiches werden auf den
Standardwert von 256 gesetzt. Die Lnge wird auf eine gerade Zahl
abgerundet. Die Wassermarken werden generell auf 1/4 (low water mark) und
3/4 (high water mark) gesetzt.
TBL:
Wie RBL, aber diesmal die Sendepufferlnge.
Mgliche Probleme
-----------------
Lange DMA-Zugriffe knnen beim Empfang zu Datenverlusten fhren. Ebenfalls
kritisch sind lange Verweilzeiten der CPU in einem Interruptpriorittslevel
grer als 5.
Auf 8MHz STs ohne Mag!X >2.00 und ohne neues NVDI (mindestens Version 2.50
vom 28.10.1993): Bei mehr als 9600Bd Finger weg von Maus und Tastatur,
whrend GSZRZ empfngt. Sonst gibt es ein paar bertragungsfehler (bei
MODEM1). Genauso knnen ein paar Zeichen verloren gehen, wenn im
Terminalprogramm gerade ein Text ankommt und der User die Tastatur oder
Maus bearbeitet.
Abspeichern empfangener Daten unter GSZRZ whrend des Empfangs fhrt bis
38400Bd meist nicht zu Fehlern.
Man kann den Blitter so programmieren, da er die CPU zu lange blockiert.
Das TOS und NVDI tun dies anscheinend nicht. Wenn Fehler beim Empfang mit
>= 38400Bd auftreten, erst mal mit abgeschaltetem Blitter probieren.
Es gibt einige ACCs und residente (AUTO-Ordner-)Programme, die irgendwelche
Interrupts umlegen und das System zu lange blockieren. Im Zweifelsfalle
einzeln rauswerfen und testen.
MiNT und besonders MultiTOS sind allgemeine Systembremsen, die sich
besonders auf 8MHz-Rechnern bemerkbar machen. Mag!X finde ich persnlich
wesentlich besser, da es wesentlich schneller ist.
DCF_TIME von Ralf Zimmermann @WI2 sollte in der Version 1.2 oder hher
verwendet werden. Aber nur die Abfrage ber den RingIndicator macht keine
Probleme bei 57600Bd, ber den Joyport gibt es sekndlich rger.
QFAX frit sehr viel Rechenzeit und sollte bei Problemen zuerst entfernt
(nicht nur abgeschaltet) werden.
Funktion des ...
----------------
Siehe DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
Versionen
---------
Diese Daten gelten fr alle MFP*.PRG, wenn nicht anders vermerkt.
1993-11-21 erste Verffentlichung
1993-11-23 bleibt auch bei Installationsfehler resident allerdings passen
dann ser. Interruptroutinen und Bco* nicht zusammen. (besser als
Totalabsturz)
1993-12-15 bei den MFP*.PRG ohne Hardwarehandshakeleitungen: TIOCSFLAGS
verbietet RTS/CTS durch Fehlermeldung ERANGE. In diesem Fall werden die
Einstellungen nicht gesetzt!
1994-01-01 Fcntl TIONOTSEND und TIOCFLUSH implementiert, DTR-Signal
nutzerdefiniert bei MFP.PRG, Puffergren durch Nutzer einstellbar
1994-03-27 Fcntl TIOCFLUSH Nr.1,2,3 gehen jetzt endlich
1994-04-07 Empfangspuffer-High-Water-Mark korrekt initialisiert
Harun Scheutzow, 21.11.1993 und spter
(Harun_Scheutzow@b.maus.de)
MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
***********************************************
(The most important parts translated from German to English on 1994-01-08
by Harun Scheutzow. I have no time for translating all. If anybody
translates the remaining parts, I'm very interested in getting the result
for including it in the next version of this package. My native language
is German, I think a person whos native language is English would do a
much better translation. Thanks! (Send only mails smaller than 16kbyte to
my email address.))
These are drivers for the interfaces realized by MFPs (eg IC MC68901
manufactured by Motorola). They work together with DRVIN.PRG or an
equivalent replacement. 1_README.TXT contains an introduction.
The general
-----------
Currently all MFP*.PRG have the same configuration possibilities.
The serial part of the MFP, the USART, is not as powerful as the one of
the SCC. That's why the MFP interfaces are more allergic against high CPU
load and lose more easy characters.
MFP.PRG
-------
MFP.PRG is made for the so called ST-MFP, which lays from address
$FFFFFA01 up in every ST, STE, MegaST, MegaSTE, TT, Stacy and STBook. The
Falcon has this MFP too, but the USART-part is used in an other way (not
used). MFP.PRG is not for the Falcon. This driver provides the BIOS-device
6 and the name "MODEM1".
MFP_TT.PRG
----------
MFP_TT.PRG supports the so called TT-MFP form address $FFFFFA81 up,
contained only in the TT until now. This driver provides the BIOS-device 8
and the name "SERIAL1".
MFP_FALC.PRG
------------
MFP_FALC.PRG is made for the users who modified their Falcon by drawing
out the serial interface of the MFP, unused in the original state. The
driver provides the BIOS-device 6 and the name "MODEM1".
(-- Mail is only in the German part --)
MFP_BAST.PRG
------------
MFP_BAST.PRG is not contained in this package. It shall support the TT-MFP
in non-TTs (for users who solder in their computers). Who is in need of
this driver, should contact me.
In the following I will describe principal the MFP.PRG:
This is a software speeder and patch for the interface MODEM1 of the Atari
computer. It removes not only the RTS/CTS-handshake bugs contained in the
TOS2.06/3.06 too, but increases with its optimized routines the possible
transfer rate.
(-- something untranslated --)
Compatibility to HSMODEM1
-------------------------
If MFP.PRG is loaded as the only one or the last driver, all programs
which run with HSMODEM1 should run with these driver to (on MODEM1).
Suppositions, ...
-----------------
Mag!X
Versions from 2.00 up of these multitask operating system (it is in
opposite to the current MTOS not only an addition to TOS) have correct
routines for the serial interfaces. The corresponding GEMDOS-functions
are absent in version 2.00. The Mag!X-multitasking on an 8MHz-ST during
38400Bd-receive (eg ZMODEM) is very nice (with a NVDI form Version 2.50
form 28.10.1993 up): It is possible to work in the foreground with
keyboard and mouse (eg in a text editor, tested with Everest) while in the
background the ZMODEM-receive (GSZRZ) runs without any errors. Such
performance became true by intelligent programming. With Mag!X from
version 2.00 up the timer interrupt routine modification should be
switched off because Mag!X has its own nice routines.
These drivers are a replacement for other patches (not only for MODEM1),
eg RS232ENC or TURBOCTS.
The interface MODEM1 runs without additional hardware with a maximum of
19200Bd. MFP.PRG can not change this. But it replaces the slow and in part
buggy routines of the TOS by fast and (I hope) error free ones. With
additional hardware as the RSVE (developed by me), or as RS-Speed (by
Stephan Skrodzki) or others baud rates higher than 19200 are provided.
RSVE allows 38400, 57600 and 115200Bd. MFP.PRG realizes in the range of
the hardware possibilities (CPU speed, MODEM speed, ...) for a higher
thruput. The complete documentation of RSVE lays in some mailboxes.
It is impossible to set the MODEM1 only by software to more than 19200Bd
in the _asynchron_ mode.
(-- something untranslated --)
Bugs of other programs
----------------------
(-- something untranslated --)
How fast it can run?
--------------------
The problem of the serial transfer with a given speed (measured in Baud)
is not the transmission of the characters but their reception.
(-- something untranslated --)
57600Bd on 8MHz and 16MHz 68000 CPUs on MODEM1
----------------------------------------------
57600Bd is the magic border of MODEM1 on (Mega)ST(E) which is achieved
only by small modifications in TOS (or by Mag!X). 115200Bd seem to be
possible by polling only.
(-- something untranslated --)
Configuration
-------------
The configuration is done by using SETTER.TTP.
Because the explainations in the drivers are German I added an
abbreviation.
FASTINT:
MFP.PRG is able to modify the timer interrupt of the TOS to achieve
57600Bd on MODEM1 on a 8MHz-68000. Should be switched off on TT/Falcon and
under Mag!X >=2.00 and during experiments with other operating systems. If
more than one MFP*.PRG is used at the same time this option sould be set
only in one of them.
Function (for interested users):
(-- something untranslated --)
RSVE:
(Only for users of the RSVE-hardware. Otherwise answer with Nein.) MFP.PRG
can create the cookie RSVE making the RSVE_SET.PRG unnecessary. The
function of HISP is done automatically.
HISP:
This setting enables the high baud rates possible with RSVE and RS_Speed
in the Fcntl-TIOC?BAUD-functions instead of 150/134/110.
REPL:
MFP.PRG can replace baud rates. This is useful only with RSVE or
RS-Speed if programs can't set 110/134/150Bd and don't know RSVE/RS_Speed.
(-- something untranslated --)
Enter on all six places u if you don't have RSVE or RS-Speed.
(-- something untranslated --)
DTR: (only for MFP.PRG)
The DTR(data terminal ready)-signal is set at the start of this driver on
time to the value given here. Yes corresponds to on and is equivalent to
the behavior of TOS, No corresponds to off and prevents most modems from
going off hook before a communication program has been started.
RBL:
Use 256 as a default. Here the receiver buffer length in byte can be set.
It may be in the range of 65534 (maximum) to 16 (minimum). Values out of
this range are set to the default of 256. The water marks are set to 1/4
(low water mark) and 3/4 (high water mark).
TBL:
As RBL, but for the transmitter buffer length.
Possible problems
-----------------
(-- something untranslated --)
Function of ...
---------------
See DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
Versions
--------
The data is valid for every MFP*.PRG if there is no special note.
(-- something untranslated --, see German part)